Computer applications that handle valuable information are normally expected to resist misuse of the information. For example, certain systems that handle valuable, copyrighted material such as electronic books, music, movies, etc., are normally expected to take some measures to resist unauthorized copying of the content that these systems handle. (A Digital Rights Management, or “DRM”, system is one example of such an application.) Such measures generally assume that a hacker is continually attempting to observe or tamper with a program's inner workings. Thus, applications that seek to prevent their own misuse generally expend some effort and resources to detect and prevent outside attempts to observe or change their inner workings.
For example, valuable content (e.g., a copyrighted song) may by protected by encryption, and an application may be trusted to handle and apply the decryption key for that content so that the content can be decrypted into cleartext and rendered. In another variation on this encryption scheme, the decryption key itself may be protected by encryption, and the application may be trusted to handle an additional decryption key that is used to decrypt the content decryption key. (E.g., the user's machine may be associated with a public/private key pair, and the decryption key for the content may be encrypted with the user's public key prior to delivery to the user's machine.) Regardless of the exact encryption scheme used, it may be the case that the software that handles the keys takes some steps to prevent the keys from being divulged. For example, various systems may obfuscate the code that applies the keys in order to make it difficult for an observer to determine which data actually constitutes the key. Other systems may obfuscate the key, such as by avoiding storing the entire key in memory at one time. While the foregoing describes a problem in terms of protecting content by protecting the key(s) that are used to decrypt the content, in greater generality the problem can be understood as there being some restricted function that requires some data to be performed (i.e., “enabling bits”), where the problem is to protect misuse or divulgence of the enabling bits.
What the above-described systems have in common is that they presume that the environment in which software runs is a dangerous place in which interlopers may be present, and they take active steps to guard against such interlopers. However, certain technologies exist that can be used in a novel way to construct a different solution to the problem of guarding keys or other enabling bits. These technologies include the following:
Trusted Cryptography Module
FIG. 1 shows a trusted cryptography module 8 that exposes certain functions. (Trusted Cryptography Module 8 is sometimes referred to as a Trusted Platform Module, or “TPM”.) Trusted cryptography module 8 maintains a key pair 10, which comprises public key 12 and private key 14. (Typically, each machine on which trusted cryptography module 8 is installed has its own version of key pair 10, so that each machine is associated with its own key pair.) It may be the case that public key 12 is generally known. However, one feature of trusted cryptography module 8 is to perform cryptographic operations using private key 14 without divulgence of private key 14 outside of trusted cryptography module 8. While it will be understood that no computer system is infallible or impervious to attack, trusted cryptography module 8 is presumed to be effective, to a high degree of reliability, at preventing private key 14 from being divulged. Trusted cryptography module 8 is “trusted” to the extent of its effectiveness at preventing divulgence of private key 14.
Trusted cryptography module 8 exposes certain functions that apply key pair 10 to certain input data. These functions include PkSeal 16, PkUnseal 18, and, optionally, Quote 20. These functions operate as follows:
PkSeal 16 is a function that receives as input: text 22 that is to be encrypted, and a rule 24. PkSeal 16 encrypts text 22 and rule 24 together with public key 12, so that the output of PkSeal 16 is an encrypted combination 26 that of text 22 and rule 24.
PkUnseal 18 receives the encrypted combination 26 of text 22 and rule 24, and returns the original (decrypted) text 22 if rule 24 is satisfied—i.e., PkUnseal 18 decrypts the ciphertext that it receives as input, but only if the rule associated with that ciphertext is satisfied.
Typically, rule 24 comprises a requirement that the ciphertext be decrypted only when the decryption is requested by a particular entity. In this case, rule 24 may be represented simply as the hash of the entity that is allowed to request decryption of a particular ciphermessage. In one embodiment the entity could represent the software that is making the call to the TPM, i.e., where hashing the entity directly identifies the software and thus validates the software. Thus, for example, there may be several entities (e.g., computer programs, operating systems, etc.) on a particular machine that can use PkSeal 16 and PkUnseal 18, and if a first entity wants to “seal” a particular message to a second entity (i.e., if the first entity wants to encrypt a message so that the message is decryptable only by the second entity), then the first entity can provide the message to be encrypted to PkSeal 16, while using the hash of the second entity as the rule 24. The output of PkSeal 16 can later be provided as input to PkUnseal 18. However PkUnseal 18 will verify the hash of the entity that calls PkUnseal, and will only provide the decrypted message if the hash of the calling entity matches the hash that is encrypted together with the message.
Trusted cryptography module also exposes Quote 20, which combines a digital signing function with a way to verify the identity of the entity that directs the signing. (Digital signatures are known in the relevant art, and are not described in detail herein.) Quote 20 receives text 22 as input, and returns a digital signature (generated using private key 14) that is based not only on text 22, but also the hash 30 of the entity that invoked Quote 20. The functions of trusted cryptography module 8 may be invoked by various different entities on a single machine (e.g., the functions may be invoked by different operating systems, drivers, or application programs), and the signature generated by Quote 20 is based not only on the text that the caller of Quote 20 provides as input, but also on a hash of that caller, so that the subsequent verifier of the signature can determine who directed that a particular item of data be signed. (It is possible to sign bad data as well as good data. For example, an entity may sign a public key as an averment that the signing entity believes the public key to be associated with a trustworthy source. Quote 20 does not attempt to determine the veracity of that averment, but generates a signature that is partially based on the hash of the entity that directs the signing, so that the identity of that entity can later be verified. The subsequent verifier can then determine whether it trusts the entity that directs the signing, and, based on that trust, can make a judgment as to the reliability of the averment represented by the signing. Quote 20 supports this type of judgment by ensuring that the identity of the entity that directs the signing is bound with the signature.)
Trusted cryptography module 8 may be a dedicated hardware device that is incorporated into a computer—e.g., a chip that resides on the motherboard of a computer, and that maintains some type of physical barrier or physical tamper resistance to prevent divulgence of key pair 10 under inappropriate circumstances. However, the functionality of cryptography module 8 may be implemented as software rather than hardware.
Environment Isolation
FIG. 2 is a block diagram of a computer 60 on which plural, mutually isolated environments are supported. Environments 42(1), 42(2), . . . 42(n) are environments that are mutually isolated from each other in the sense that actions arising in one environment (e.g., environment 42(1)) do not directly affect another environment (e.g., environment 42(2)). Isolation among environments is represented by separations 44. Separations 44 do not necessarily represent physical separation of environments, but rather are separations that may be enforced by a software component such as hypervisor 40.
Hypervisor 40 is a software component that runs on computer 60 and whose functions are to: (1) allow plural environments to run on a single computer 60, and (2) allow each of the environments to operate as if it is the only environment running on computer 60 without the environment having to be concerned with interference from one of the other environments. The portion of hypervisor 40 that provides function (2) is effectively the software that implements separations 44.
Hypervisor 40 can be implemented in a variety of ways, which are known in the relevant art and are therefore not described in detail herein. In one example, hypervisor 40 can expose “virtual hardware” to each of several partitions, so that each environment control the virtual hardware and hypervisor 40 manipulates the actual hardware based on each environment's instructions to control the virtual hardware. In this case, hypervisor 40 manipulates the actual hardware in a way that does not allow the instructions that one environment gives to its virtual hardware to affect another environment.
Environments 42(1), 42(2), . . . , 42(n) can be different operating systems running side-by-side on a single machine. However, programs that do not have the functionality of a traditional operating system can operate as environments within FIG. 2. For example, an application-level program can be configured to run as an environment.
Optionally, computer 60 may include trusted cryptography module 8. Moreover, each of environments 42(1), 42(2), . . . , 42(n) may direct the sealing, unsealing, and quoting of data. Thus, environment 42(1) may use PkSeal 16 to encrypt the data with a hash of environment 42(2) as the associated “rule.” Environment 42(2) may then acquire this data (although not necessarily directly from environment 42(1), since hypervisor 40 enforces separation between environments 42(1) and 42(2)), and environment 42(2) may then us PkUnseal 18 to decrypt the data, but PkUnseal 18 will determine, before providing the encrypted data to environment 42(2), that environment 42(2) hashes to the value named as the rule. Also, environment 42(1) can use Quote 20 to sign data, and then pass this signed data to environment 42(2). Environment 42(2) can then verify the signature on the data, and can also verify that the data was signed by trusted cryptography module 8 at the request of environment 42(1). Environment 42(2) can then make a determination about whether it trusts data signed by environment 42(1).
While the above described cryptography module and isolation technologies exist independently, it would be useful to combine and manipulate them, in a way that has not yet been realized in the prior art, to effectuate certain types of security and data protection applications.